Communication control method and apparatus, and communication system

ABSTRACT

A printer has a queue for queuing a queued execution command, an immediate execution agent for executing a write command, and a queued execution agent for executing a read command. The immediate execution agent immediately executes the received write command, and writes data in a host. The queued execution agent picks up a read command from the queue, and reads out data from the host. The host appends a data transfer request from the printer to a queue, issues a write command to the printer on the basis of that data transfer request, and issues a read command to the printer on the basis of a print data transmission request or the like from an application. Independent full-duplex channels can be provided in two directions. Also, a write command can be immediately processed.

BACKGROUND OF THE INVENTION

[0001] The present invention relates to a communication control methodand apparatus for connecting apparatuses such as a host computer andprinter.

[0002] In recent years, an IEEE1394 interface is used for connecting acomputer and peripheral apparatus, or connecting peripheral apparatuses.The IEEE1394 interface allows higher-speed, two-way communications ascompared to a hand-shake scheme such as a Centronics interface. Also,the IEEE1394 interface is a memory bus model interface, and equipmentsconnected via the IEEE1394 interface can read data from the designatedaddress of a connected equipment and can write data at the designatedaddress.

[0003] IEEE1394 defines the protocol of the physical and link layersutilized in many applications, but does not define detailed protocols inunits of equipments. For this reason, the protocol of the transportlayer such as SBP (Serial Bus Protocol)-2 that uses IEEE1394 as thephysical and link layers has been proposed. The transport layer providesa data transfer function to an application, and applications which usethis layer can exchange data with each other.

[0004] The protocol SBP-2 utilizes the features of the memory bus modelof IEEE1394, and with this protocol, the data receiving side can receivedata as its resources become available.

[0005] In SBP-2, when data is to be transferred, the transmitting sideperforms operation called a login to establish a channel with acommunication partner. In this case, the logged-in side is called aninitiator, and the partner is called a target. Data transfer is done insuch a manner that the target reads/write data from/to the initiator inaccordance with an instruction from the initiator. In this scheme, theinitiator generates an ORB (Operation Request Block) that contains thestorage address, size, and the like of data to be transmitted after thelogin, and informs the target of the address of that ORB. The targetreads out data from the initiator on the basis of the address and sizewritten in the ORB and processes the readout data, or writes data as itsresources become available. After such processing, the target generatesa status block to inform the initiator of the processing state.

[0006] When a communication is made using SBP-2 built based on IEEE1394,especially when SBP-2 is applied to data transfer from a data sourcesuch as a host computer or the like, which serves as an initiator, to aperipheral apparatus such as a printer apparatus, which serves as atarget, the following two problems are posed.

[0007] (1) The procedure is complex due to full-duplex communications.

[0008] In SBP-2, data transfer is basically managed by the initiator,and the target cannot asynchronously transfer data to the initiator. InSBP-2, when the target wants to transfer data to the initiator, it sendsa data read request using unsolicited status to the initiator. Theinitiator generates an ORB in response to the request, and adds thegenerated ORB to the end of a list of pending ORBs (including a datatransfer request from the initiator to the target, and the like). TheseORBs are processed in turn from the oldest one. For this reason, onlywhen the ORB processing of the initiator side has progressed, and theinitiator processes the ORB generated in response to the data readrequest from the target, the target can transfer data to the initiator.That is, the data transfer timing from the target to the initiator isnot the issuance timing of the read request from the target to theinitiator but is delayed from that timing by the time required forprocessing the pending ORBs. As a result, two-way, asynchronous datatransfer cannot be done. When data to be transferred from the target tothe initiator is generated asynchronously, for example, when the targetis a printer and an error occurs in that printer, the data to beimmediately transmitted to the initiator cannot be transferred in realtime.

[0009] For this reason, in order to transfer data asynchronouslygenerated by a printer to a host in real time, the printer mustundertake a login procedure as an initiator, and must perform datatransfer to the host computer as a target.

[0010] In this way, when the host computer and printer log in eachother, and they both serve as an initiator and target, they must bothown processes as an initiator and target. The printer must also performa login.

[0011] A peripheral apparatus such as a printer which processes an imageconsumes large volumes of memory and processor resources for imageprocessing. For this reason, in order to reduce the cost by simplifyingthe apparatus arrangement and to attain quick processing, resources usedfor purposes other than image processing must be reduced as much aspossible. However, when the printer must run many processes, asdescribed above, many resources are consumed accordingly, thusdisturbing a cost reduction and efficient processing.

[0012] On the other hand, data that flow between the host computer andprinter are related to each other like print data and its processingstatus. If channels are set in two ways by independent login processes,their data and responses must be related to each other, and a newprocessing protocol therefor must be added.

[0013] In this way, it is inappropriate to directly apply IEEE1394 andSBP-2 to communications between the host computer and printer, and it ishard to reduce required resources in the respective apparatuses and toimprove efficiency.

[0014] (2) Multi-channels cannot be realized.

[0015] Recently, a multi-functional machine that combines variousfunctions is popularly used as a peripheral apparatus. For example, adigital multi-functional machine which allows a host computer to use itas a scanner, printer, and facsimile is known. When such apparatus isused, a plurality of functions can be simultaneously used ifcommunications are made via a plurality of independent channels in unitsof functions.

[0016] However, since SBP-2 cannot provide multi-channels, it isdifficult to use such unit functions simultaneously.

[0017] Some protocols other than SBP-2 can transfer asynchronouslygenerated data and can realize multi-channels. However, such protocolscannot utilize the features of IEEE1394 as the memory bus model. Thatis, when such protocols are applied to communications between the hostand printer, the printer cannot perform data transfer at itsconvenience, and the host must perform data transfer while monitoringthe printer state.

SUMMARY OF THE INVENTION

[0018] The present invention has been made in consideration of theaforementioned prior art, and has as its object to provide acommunication control method and apparatus, which can make full-duplexcommunications (asynchronous two-way communications) by a single loginprocess, and can efficiently utilize resources such as processes,memories, and the like required for data exchange, and a printerapparatus using the method.

[0019] It is another object of the present invention to provide acommunication control method and apparatus, which allows a target toread out data prepared by an initiator as soon as its resources becomeavailable, and can prevent the initiator from being occupied by datatransfer on the convenience of the target, and a printer apparatus usingthe method.

[0020] It is still another object of the present invention to provide acommunication control method and apparatus which can realizemulti-channels, and a printer apparatus using the same.

[0021] In order to achieve the above object, the present inventioncomprises the following arrangement.

[0022] That is, there is provided a communication control method ofexchanging data upon accessing a storage area of an initiator from atarget,

[0023] wherein the initiator transmits commands corresponding to readand write accesses to the storage area to the target so as not to exceedthe number of read and write commands that can be held by the target,and

[0024] the target holds the received read and write commands indifferent queues, and independently processes the held commands.

[0025] There is also provided a communication control method ofexchanging data upon accessing a storage area of an initiator from atarget,

[0026] wherein the target checks if a size of data to be transmittedexceeds a predetermined size, requests the initiator to issue a writecommand in the storage area when the size of the data to be transmittedexceeds the predetermined size, and sends the data to the initiator whenthe size of the data to be transmitted does not exceed the predeterminedsize, and

[0027] the initiator issues a write command upon receiving a writecommand issuance request from the target.

[0028] There is also provided a communication system for exchanging dataupon accessing a storage area of an initiator from a target,

[0029] wherein the initiator transmits commands corresponding to readand write accesses to the storage area to the target so as not to exceedthe number of read and write commands that can be held by the target,and

[0030] the target holds the received read and write commands indifferent queues, and independently processes the held commands.

[0031] There is also provided a communication system for exchanging dataupon accessing a storage area of an initiator from a target,

[0032] wherein the target checks if a size of data to be transmittedexceeds a predetermined size, requests the initiator to issue a writecommand in the storage area when the size of the data to be transmittedexceeds the predetermined size, and sends the data to the initiator whenthe size of the data to be transmitted does not exceed the predeterminedsize, and

[0033] the initiator issues a write command upon receiving a writecommand issuance request from the target.

[0034] There is also provided a communication control method ofexchanging data with a target upon accessing a storage area in a memoryfrom the target connected via a communication, comprising:

[0035] the queuing step of receiving a spontaneous request from thetarget and queuing the request in a queue; and

[0036] the command generation step of generating and transmitting readand write commands to the storage area in response to a request from anapplication or the target so as not to exceed the number of read andwrite commands that can be held by the target.

[0037] There is also provided a communication control method ofexchanging data with an initiator upon accessing a storage area of theinitiator connected via a communication, comprising:

[0038] the queuing step of queuing a read command received from theinitiator in a queue having a predetermined size;

[0039] the queued execution step of picking up and executing a readcommand from the queue;

[0040] the immediate execution step of executing a write commandreceived from the initiator immediately after reception; and

[0041] the transfer request step of issuing a data transfer request tothe initiator.

[0042] There is also provided a communication control apparatus forexchanging data with a target via a storage area, comprising:

[0043] means for communicating with a target;

[0044] a memory including the storage area;

[0045] queue management means for queuing a spontaneous request from thetarget; and

[0046] command generation means for generating and transmitting read andwrite commands with respect to the storage area in response to a requestfrom an application or the target so as not to exceed the number of readand write commands that can be held by the target.

[0047] There is also provided a communication control apparatus forexchanging data with an initiator by accessing a storage area of theinitiator, comprising:

[0048] means for communicating with the initiator;

[0049] a queue which holds a read command received from the initiatorand has a predetermined size;

[0050] queued execution means for picking up and executing the readcommand from the queue;

[0051] immediate execution means for executing a write command receivedfrom the initiator immediately after reception; and

[0052] transfer request means for issuing a data transfer request to theinitiator.

[0053] There is also provided a computer readable storage medium, whichstores a communication control program for exchanging data by accessinga storage area from a target via a communication, the programcomprising:

[0054] queue management means for queuing a spontaneous request from thetarget; and

[0055] command generation means for generating and transmitting read andwrite commands with respect to the storage area in response to a requestfrom an application or the target so as not to exceed the number of readand write commands that can be held by the target.

[0056] There is also provided a computer readable storage medium, whichstores a communication control program for exchanging data by accessinga storage area of an initiator connected via a communication, theprogram comprising:

[0057] queue management means for queuing a read command received fromthe initiator in a queue having a predetermined capacity;

[0058] queued execution means for picking up and executing the readcommand from the queue;

[0059] immediate execution means for executing a write command receivedfrom the initiator immediately after reception; and

[0060] transfer request means for issuing a data transfer request to theinitiator.

[0061] There is also provided a printing system using a communicationcontrol method in which an initiator transmits commands corresponding toread and write accesses to a storage area to a target so as not toexceed the number of read and write commands that can be held by thetarget, and the target holds the received read and write commands indifferent queues, and independently processes the held commands, whereina host apparatus serving as an initiator is connected to a printerapparatus serving as a target, the printer apparatus receives print datafrom the host apparatus and prints out based on the received print data,and the host apparatus receives status information of the printerapparatus.

[0062] There is also provided a printing control apparatus fortransmitting print data to a target, and receiving status informationfrom the target, in a communication control method which comprises thequeuing step of receiving a spontaneous request from the target andqueuing the request in a queue, and the command generation step ofgenerating and transmitting read and write commands to the storage areain response to a request from an application or the target so as not toexceed the number of read and write commands that can be held by thetarget.

[0063] There is also provided a printing apparatus for receiving printdata from an initiator, and transmitting status information to theinitiator, by a communication control method which comprises the queuingstep of queuing a read command received from the initiator in a queuehaving a predetermined size, the queued execution step of picking up andexecuting a read command from the queue, the immediate execution step ofexecuting a write command received from the initiator immediately afterreception, and the transfer request step of issuing a data transferrequest to the initiator.

[0064] Other features and advantages of the present invention will beapparent from the following description taken in conjunction with theaccompanying drawings, in which like reference characters designate thesame or similar parts throughout the figures thereof.

BRIEF DESCRIPTION OF THE DRAWINGS

[0065] The accompanying drawings, which are incorporated in andconstitute a part of the specification, illustrate embodiments of theinvention and, together with the description, serve to explain theprinciples of the invention.

[0066]FIG. 1 is a block diagram of a target (printer);

[0067]FIG. 2 is a block diagram of an initiator (host computer);

[0068]FIGS. 3A and 3B show the general format of an ORB;

[0069]FIG. 4 shows the format of a QUEUE DEPTH command ORB;

[0070]FIG. 5 shows the format of a DATA TRANSFER command ORB;

[0071]FIG. 6 shows the format of a REQUESTED READ command ORB;

[0072]FIG. 7 shows the format of a DIRECT STATUS RESPONSE command ORB;

[0073]FIGS. 8A and 8B show the format of an ACQUIRE DEVICE RESOURCEcommand ORB;

[0074]FIG. 9 shows the format of a data resource release command ORB;

[0075]FIG. 10 shows the format of a BASIC DEVICE STATUS command ORB;

[0076]FIGS. 11A and 11B show the general format of a status block;

[0077]FIG. 12 shows the format of a QUEUE DEPTH status block;

[0078]FIG. 13 shows the format of a DATA TRANSFER status block;

[0079]FIG. 14 is a flow chart showing the processing procedure executedby the initiator in response to a generated data transfer request;

[0080]FIG. 15 is a flow chart showing the processing procedure executedby a fetch agent of the target upon write in a DOORBELL register;

[0081]FIG. 16 is a flow chart showing the processing procedure executedby an execution agent upon reception of an ORB message from the fetchagent;

[0082]FIG. 17 is a flow chart showing the processing procedure executedby the target in response to a generated data transfer request;

[0083]FIG. 18 is a flow chart showing the processing procedure executedby the initiator upon write in a status register;

[0084]FIG. 19 shows the data transfer sequence from the initiator (hostcomputer) to the target (printer);

[0085]FIG. 20 shows the sequence upon data transfer from the target tothe initiator using READ REQUEST status;

[0086]FIG. 21 shows the sequence upon data transfer from the target tothe initiator using DIRECT status;

[0087]FIG. 22 is a block diagram of a target that providesmulti-channels;

[0088]FIG. 23 is a block diagram of an initiator that providesmulti-channels;

[0089]FIG. 24 shows the format of a multi-channeled DATA TRANSFERcommand ORB;

[0090]FIG. 25 shows the format of a multi-channeled REQUESTED READcommand ORB;

[0091]FIG. 26 shows the format of a multi-channeled DIRECT STATUSRESPONSE command ORB;

[0092]FIGS. 27A and 27B show the format of a multi-channeled ACQUIREDEVICE RESOURCE command ORB;

[0093]FIG. 28 shows the format of a multi-channeled RELEASE DEVICERESOURCE command ORB;

[0094]FIG. 29 shows the format of a multi-channeled ABDICATE DEVICERESOURCE RESPONSE command ORB;

[0095]FIG. 30 shows the format of a multi-channeled BASIC DEVICE STATUScommand ORB;

[0096]FIGS. 31A and 31B show the format of an OPEN CHANNEL REQUESTresponse;

[0097]FIGS. 32A and 32B show the format of a CLOSE CHANNEL REQUESTresponse;

[0098]FIGS. 33A to 33C show the general format of a multi-channeledstatus block;

[0099]FIG. 34 shows the format of a multi-channeled DATA TRANSFER statusblock;

[0100]FIG. 35 shows the format of a multi-channeled DIRECT status block;

[0101]FIG. 36 shows the format of a multi-channeled DEVICE RESOURCEACQUIRE status block;

[0102]FIG. 37 shows the format of a multi-channeled ABDICATE DEVICERESOURCE status block;

[0103]FIG. 38 shows the format of a multi-channeled BASIC DEVICE statusblock;

[0104]FIG. 39A is a flow chart showing the processing procedure executedby the multi-channeled initiator upon write in a status register;

[0105]FIG. 39B is a flow chart showing the processing procedure executedby the multi-channeled target upon write in a DOORBELL register; and

[0106]FIG. 40 is a block diagram showing the hardware arrangement of aprinter system using an IEEE1394 interface.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0107] First Embodiment

[0108] A printing system which connects a host computer and printer viaIEEE1394 will be described below as the first embodiment of the presentinvention. In this system, data transfer is done in accordance with aprotocol according to the present invention (to be referred to as HPThereinafter), which uses SBP-2 built on IEEE1394. FIG. 40 shows thehardware arrangement in that printing system.

[0109] Hardware Arrangement of System

[0110] In FIG. 40, a host computer 200 comprises a CPU 1 that processesdocuments including figures, images, characters, tables (containingtable calculations and the like), and so forth on the basis of adocument processing program stored in a program ROM area in a ROM 3. TheCPU 1 systematically controls the respective devices connected to asystem bus 4. The program ROM area of the ROM 3 stores a control programfor the CPU 1 and the like, a font ROM area of the ROM 3 stores fontdata and the like used in the document processing, and a data ROM areaof the ROM 3 stores various data used upon executing the documentprocessing and the like. A RAM 2 serves as a main memory, work area, andthe like of the CPU 1. Programs may be stored in the RAM 2. On the RAM2, a transmission data buffer and a system memory for storing ORBs areassured.

[0111] A keyboard controller (KBC) 5 controls key inputs from a keyboard9 and a pointing device (not shown). A CRT controller (CRTC) 6 controlsdisplay on a CRT display (CRT) 10. A memory controller (MC) 7 controlsaccesses to an external memory 11 such as a hard disk (HD), floppy disk(FD), and the like that store a boot program, various applicationprograms, font data, user file, edit file, and so forth. A 1394interface 8 is connected to a printer 100 according to the IEEE1394standard, and implements communication control with the printer 100.Note that the CPU 1, for example, maps (rasterizes) outline font dataonto a display information RAM area allocated on the RAM 2 to realize aWYSIWYG environment on the CRT 10. The CPU 1 opens various registeredwindows on the basis of commands designated by a mouse cursor (notshown) or the like, and executes various kinds of data processing.

[0112] In the printer 100, a printer CPU 12 systematically controlsaccesses to various devices connected to a system bus 15 on the basis ofa control program stored in a program ROM area of a ROM 13 or a controlprogram stored in an external memory 14, and outputs an image signal asoutput information to a printer unit (printer engine) 17 connected via aprinter unit interface 16. The program ROM area of the ROM 13 alsostores a control program for the CPU 12, that implements various agents(to be described later). A font ROM area of the ROM 13 stores font dataand the like used upon generating the output information, and a data ROMarea of the ROM 13 stores information and the like used on the hostcomputer in case of the printer which has no external memory 14 such asa hard disk or the like. The CPU 12 can communicate with the hostcomputer via a 1394 interface 18, and can inform the host computer 200of information and the like in the printer.

[0113] A RAM 19 serves as a main memory, work area, and the like of theCPU 12, and its memory capacity can be expanded using an option RAMconnected to an expansion port (not shown). Note that the RAM 19 is usedas an output information mapping area, environment data storage area,NVRAM, and the like.

[0114] A memory controller (MC) 20 controls accesses to theabove-mentioned external memory 14 such as a hard disk (HD), IC card, orthe like. The external memory 14 is connected as an option, and storesfont data, emulation program, form data, and the like. A control panel(console) 1002 is provided with operation switches, LED indicators, andthe like. The number of external memories is not limited to one, and theprinter may comprise more than one external memories, so that aplurality of external memories including an option font card includingoption fonts in addition to internal fonts, an external memory thatstores programs for interpreting other printer control languages, andthe like may be connected. Furthermore, an NVRAM (not shown) may beadded, and may store printer mode setup information from the controlpanel 1002.

[0115] Arrangement of Initiator

[0116]FIGS. 1 and 2 show a communication system which uses the printer100 as a target, and the host computer 200 as an initiator in theabove-mentioned hardware arrangement. In this embodiment, sucharrangements are implemented when the CPUs in the host computer andprinter execute predetermined programs. The initiator shown in FIG. 2will be described first.

[0117] In FIG. 2, in the host computer serving as the initiator, aprinter driver 209 as an application issues a data transfer request to aprinter via an HPT processor 203, and receives a response (reply) fromthe printer.

[0118] The HPT processor 203 includes an ORB manager 206. The ORBmanager 206 manages ORBs generated in a system memory 208. An ORB is ablock that stores the address, size, and the like of a data buffer to betransferred from the host computer to the printer and vice versa. ORBsare linked in turn to form an ORB list. For these ORBs, the followingprocessing rules are defined:

[0119] (1) ORBs in the ORB list are processed in turn in the FIFO order.Upon reception of a completion message (status block), the correspondingORB is deleted from the ORB list.

[0120] (2) A newly generated ORB is added to the end of the ORB list.

[0121] (3) The maximum number of ORBs that can be linked to the ORB listis the same as the total capacity of two queues in the printer, as willbe described later.

[0122] In order to implement item (3), the ORB manager 206 prepares twocounters in correspondence with the two queues of the printer. Onecounter is named CurrentQuedQUE, and indicates the current number ofempty positions in the prefetch queue (to be described later) in theprinter. The other counter is named CurrentImmediateQUE. The queuecapacity corresponding to this counter is 1 in this embodiment, and onlyan entry which is being processed can be queued. The contents of thesecounters are incremented/decremented in correspondence withgeneration/deletion of ORBs.

[0123] When the host computer generates an ORB, it writes an arbitraryvalue in a register called a DOORBELL register to inform the printer ofgeneration of an ORB. This procedure is specified in SBP-2, and isdescribed in its manual or the like.

[0124] The HPT processor 203 includes a status queue 204 and queueprocessor 205. Status received via the 1394 interface is identified by astatus identifier 202, and is directly sent to the ORB manager 206 or isadded to the status queue 204 depending on the type of status. Thestatus appended to the status queue 204 is processed by the queueprocessor 205 in the FIFO order. There are two types of status.

[0125] (1) Normal status . . . This status is a status block thatnotifies the data transfer result between the host computer and printer,and is directly sent to the ORB manager 206.

[0126] (2) Unsolicited status . . . This status is a status blockindicating that asynchronous data to be transferred from the printer tothe host computer has been generated, and is added to the status queue204. Normally, this status is spontaneously issued by the printer.

[0127] These status types are discriminated by values written in statusblocks.

[0128] A status register 210 is a register in which the printer writesdata to indicate the presence of data to be read by the host computer.

[0129] The host computer serving as the initiator has the aforementionedfunctional arrangement.

[0130] Arrangement of Target

[0131]FIG. 1 is a block diagram showing the functional arrangement ofthe printer serving as the target.

[0132] In FIG. 1, a DOORBELL register 108 is a register in which thehost computer writes data. Writing an arbitrary value in the DOORBELLregister means generation of a new ORB. A command fetch agent 103 readsan ORB via a 1394 interface 101, and appends the read ORB to a prefetchqueue 104 or sends it to an immediate execution agent 106 depending onits type. The type of command is determined with reference to a fieldindicating immediate or queued execution. However, in practice, thisfield corresponds to the function of command. For example, in thisembodiment, a command for data transfer from the target to the initiator(REQUESTED READ command) and a command for capturing the target stateare immediate execution commands, and a command for transferring printdata from the initiator to the target or the like is a queued executioncommand.

[0133] A queued execution agent 105 and the immediate execution agent106 read data from a buffer of the host computer or write data suppliedfrom a data processor 107 in accordance with the contents of an ORB readby the command fetch agent 103. After that, these agents return normalstatus to the host computer.

[0134] Furthermore, the immediate execution agent 106 sends unsolicitedstatus to the host computer in response to a data transfer request fromthe data processor 107 which performs rasterization for generatingraster data by interpreting and executing PDL, and device management. Abus interface 102 is used for accessing a desired memory location on thesystem memory 208 of the host computer 200 from the printer 100.

[0135] In the system of this embodiment, the queued execution agent isused for data transfer ORBs from the host computer to the printer, andthe immediate execution agent is used for data transfer ORBs from theprinter to the host computer.

[0136] The arrangements and operations of the initiator and target havebeen briefly explained. Prior to a detailed description thereof, thecontents of an ORB will be explained in detail below.

[0137] Contents of Command ORB (Operation Request Block)

[0138]FIGS. 3A and 3B show the general format of an ORB. In FIG. 3A, a“Next_ORB” (link) field 301 stores a link to the next ORB. If there isno next ORB, a predetermined value indicating it is stored. Note thatthe first ORB is indicated by a predetermined address register. A“data_descriptor” (data address) field 302 indicates address in the databuffer. A “d” (direction) field 303 indicates data transfer (0: write)from the host computer to the printer or data transfer (1: read) fromthe printer to the host computer. A “data_size” (data size) field 304indicates the size of the data buffer indicated by the address field302. These “Next_ORB” field 301 to “data_size” field 304 are thosespecified in SBP-2, and fields 305 to 308 to be described below are usedin processing unique to HPT.

[0139] An “i” field (immediate bit) 305 indicates whether that ORB is tobe executed by the immediate or queued execution agent in the target. Ifthe value in that field is “0”, i.e., the queued execution agent, theORB is placed in the prefetch queue; if the value is “1”, the ORB isprocessed by the immediate execution agent. A “function” (function)field 306 indicates the meaning of the ORB, as shown in FIG. 3B. Thiswill be described in detail later. A “command_block_length” (commandlength) field 307 indicates the length of a “control_block” (controlblock) field 308. The control block field 308 stores various values incorrespondence with the value in the function field 306.

[0140] The contents of an ORB will be explained in units of functions.

[0141] QUEUE DEPTH Command

[0142]FIG. 4 shows a QUEUE DEPTH command ORB of function=0. This commandis used for obtaining the depth of the prefetch queue 104 of the target.The immediate bit is set at “1”.

[0143] A control block of this command includes two fields, i.e., a“source_ID” (source ID) field 401 and “status_queue_depth” (status queuedepth) field 402. The source ID field stores the identifier of a processthat has logged in the initiator. In the example shown in FIG. 2, thelogged-in process is the printer driver. This field is added to allowthe target to identify the process to respond when a plurality ofprocesses have been logged in. The status queue depth field 402 informsthe target of the depth of the status queue 204 of the initiator.

[0144] The status queue depth field is used for managing the number ofunsolicited status blocks queued in the status queue in the target. Thetarget manages the depth of the status queue in accordance with thegeneration/processing completion message of unsolicited status in thesame manner as management of the prefetch queue by the initiator.

[0145] Upon reception of the QUEUE DEPTH command, the target stores thestatus queue length in a counter CurrentUnsolicitedQUE, and returns theprefetch queue length to the initiator. The initiator manages the numberof ORBs queued in the target in correspondence with generation anddeletion of ORBs on the basis of the queue depth of the prefetch queueobtained by this command.

[0146] DATA TRANSFER Command

[0147]FIG. 5 shows a DATA TRANSFER command of function=1. This commandis used upon transferring data from the initiator to the target. A“page_table_present” bit 501 indicates the presence of a page table.When a page table is present, the page size to be referred to by thepage table is set in a “page_size” field 502. The data buffer to betransferred is indicated by this page table, an address 503, and a datasize 504.

[0148] Upon reception of the DATA TRANSFER command, the target writesdata in the designated data buffer or reads out data therefrom inaccordance with the value in a direction field.

[0149] REQUESTED READ Command

[0150]FIG. 6 shows a REQUESTED READ command of function=2. This commandsprovides a data buffer in which data is to be written to the printerwhen “READ REQUEST status”, i.e., a data transfer request from theprinter as the target to the host is sent from the target. A“Sequence_number” (sequence number) field 601 is set with the same valueas the sequence number appended to the corresponding READ REQUESTstatus, which instigated issuance of this command. This value is anumber which makes REQUESTED READ status and REQUESTED READ commandcorrespond to each other. The format of other fields is the same as thatin the DATA TRANSFER command. In this command, the immediate bit is setat “1”, and the direction bit is also set at “1” (read). The reason whythe immediate bit is set at “1” is to immediately respond to READREQUEST status issued by the target. The buffer size uses a valuedesignated by READ REQUEST status.

[0151] Upon reception of the DATA TRANSFER command, the target writesdata in the designated data buffer assured on the system memory of theinitiator.

[0152] DIRECT STATUS RESPONSE Command

[0153]FIG. 7 shows a DIRECT STATUS RESPONSE command ORB of function=3.This command is issued in response to READ REQUEST status when theinitiator makes the target abdicate a read request. Alternatively, thiscommand is used as a reply to the target in response to DIRECT statusfrom the target. A “sequence_number” (sequence number) field 701 is setwith the same value as the sequence number appended to the correspondingREAD REQUEST status or DIRECT status, which instigated issuance of thiscommand. The format of other fields is the same as that in the DATATRANSFER command. In this command, the immediate bit is set at “1”.

[0154] Upon reception of the DIRECT STATUS RESPONSE command, the targetabdicates a read request if it has issued the READ REQUEST status havingthe corresponding sequence number.

[0155] ACQUIRE DEVICE RESOURCE Command

[0156]FIG. 8A shows an ACQUIRE DEVICE RESOURCE command ORB offunction=8. The meaning of a “resource_ID” (resource ID) field 801 is asshown in FIG. 8B. “0” is a value that depends on the device class usedand logical unit characteristics. In this system, “0” indicates theprinter as a device class and print service as logical unitcharacteristics.

[0157] Upon receiving this ACQUIRE DEVICE RESOURCE command, the targetassigns the resource designated by the resource ID to the initiator asthe sender of this command.

[0158] RELEASE DEVICE RESOURCE Command

[0159]FIG. 9 shows a RELEASE DEVICE RESOURCE command of function=9. Themeaning of a “resource_ID” (resource ID) field 801 is as shown in FIG.8B.

[0160] Upon receiving the RELEASE DEVICE RESOURCE command, the targetreleases the resource designated by the resource ID.

[0161] BASIC DEVICE STATUS Command

[0162]FIG. 10 shows a BASIC DEVICE STATUS command ORB of function=A(Hex).

[0163] Upon reception of this command, the target replies its own statusto the initiator while encapsulating it in a basic device status block.By issuing this command, the initiator can recognize the printer status.In the printer, for example, various kinds of status information relatedto the printer such as the paper size, emulation supported, and the likeare sent back from the target as basic status.

[0164] Contents of Status Block

[0165]FIGS. 11A and 11B show a status block sent back from the printeras the target to the host computer as the initiator. A status block isprepared in correspondence with each aforementioned command ORB. Thestatus block is issued by the queued and immediate execution agents ofthe target.

[0166] In FIG. 11A, the first field to “ORB_offset_lo” field arespecified in SBP-2, and include fields for indicating a command ORBcorresponding to status, and the like. An “i” (immediate bit) field 1101indicates which one of the queued and immediate execution agents issuedthis status. If the value is “0”, it indicates that the status wasissued by the queued execution agent; if the value is “1”, it indicatesthat the status was issued by the immediate execution agent. An“hpt_status” (hpt status) field 1102 indicates the type of status block,as shown in FIG. 11B. An “hpt_status_dependent” field 1103 is given itsvalue depending on hpt status. A “status_length” (status length) field1104 indicates the length of a response block 1105. The status blockswill be explained below in units of types.

[0167] QUEUE DEPTH Status Block

[0168]FIG. 12 shows QUEUE DEPTH status of hpt status=0. The QUEUE DEPTHstatus is a reply from the target in response to the QUEUE DEPTHcommand, and the target sets the depth of the prefetch queue 104 in a“prefetch_queue_depth” field 1201 and sends back the status to theinitiator. With this status, the initiator can detect the size of theprefetch queue, and manages the number of ORBs generated incorrespondence with the size.

[0169] DATA TRANSFER Status Block

[0170]FIG. 13 shows DATA TRANSFER status of hpt status=1. The DATATRANSFER status is a reply from the target in response to the DATATRANSFER command, and is issued by the target upon completion ofprocessing of the DATA TRANSFER command ORB. Upon reception of thisstatus, the initiator can detect that one ORB has been processed anddeleted from the queue of the target.

[0171] READ REQUEST Status Block

[0172] This status is hpt status=2 (its format is not shown), and hasthe data buffer size to be assured by the initiator in a response block.Normally, the target issues this status not in response to the commandORB but spontaneously. The initiator issues the above-mentionedREQUESTED READ command ORB in response to this READ REQUEST status. Theprocedure for this process will be described later.

[0173] DIRECT Status Block

[0174] This status is hpt status=3 (its format is not shown), andincludes status of application level (i.e., the data processor in thetarget) in a response block. More specifically, data exchange on theapplication level is normally done using the ORB and data buffer linkedthereto. However, when data is very small and falls within the upperlimit (24 bytes in this embodiment) of the response block, anapplication-level reply is encapsulated in an HPT-level reply. Inresponse to this status, the initiator issues the DIRECT STATUS RESPONSEcommand ORB.

[0175] DEVICE RESOURCE ACQUIRE Status Block

[0176] This status is hpt status=8 (its format is not shown), and isissued by the target that has received the ACQUIRE DEVICE RESOURCEcommand and processed it.

[0177] DEVICE RESOURCE RELEASE Status Block

[0178] This status is hpt status=9 (its format is not shown), and isissued by the- target that has received the RELEASE DEVICE RESOURCEcommand and processed it.

[0179] BASIC DEVICE Status Block

[0180] This status is hpt status=A (Hex) (its format is not shown), andis issued by the target upon reception of the BASIC DEVICE STATUScommand. This status is set with predetermined device status.

[0181] The commands and status blocks used in the printing system ofthis embodiment have been described. The data exchange procedures in theinitiator and target will be explained below.

[0182] Data Transfer Request Processing from Initiator

[0183]FIG. 14 shows the procedure for informing the printer ofgeneration of a command ORB in response to a data transfer request fromthe host computer to the printer or vice versa in the host computer.

[0184] A data transfer request from an application such as the printerdriver or the like is monitored in step S1401. The data transfer requestmay be the one that informs the host computer of the presence of data tobe transferred directly from an application such as a printer driver ormay be the one that was generated in accordance with a data read requestfrom the printer. Note that status that the printer sends to the hostcomputer asynchronous with the host computer will be referred to asUnsolicited status hereinafter. On the other hand, status which isreturned as a processing completion message of a command ORB from thehost computer will be referred to as normal status hereinafter.

[0185] Upon detection of a data transfer request, it is determined instep S1402 if data transfer is executed by a queued or immediateexecution command. If data transfer is executed by an immediateexecution command, the immediate bit of an ORB is set. When an ORB isissued in response to Unsolicited status from the printer, data transferis executed by an immediate execution command; when an ORB is issued inresponse to a data transfer request from the application of the hostcomputer, data transfer is executed by a queued execution command.

[0186] In case of queued execution, it is checked in step S1403 if thecounter CurrentQuedQUE is “0”. Upon power ON or resetting, the depth ofthe prefetch queue of the printer is read by the QUEUE DEPTH command,and is set as the default value of the counter CurrentQuedQUE. Morespecifically, the counter CurrentQuedQUE counts the current number ofempty positions in the prefetch queue. If it is determined in step S1403that the number of empty positions is “0”, since the prefetch queue ofthe target is not empty, the control waits until the queue has an emptyposition. If an empty position is found, the value of the counterCurrentQuedQUE is decremented by 1 in step S1404, and a data transferORB is generated and is linked to the ORB list in step S1407. Afterthat, an arbitrary value is written in the DOORBELL register 108 of theprinter in step S1408, thus informing the target of generation of a newORB.

[0187] On the other hand, if it is determined in step S1402 that datatransfer is done by an immediate execution command, it is checked instep S1405 if the value of the counter CurrentImmediateQUE is largerthan “0”. Note that no queue is prepared for the immediate executionagent of the target and, hence, the maximum value of this counter is“1”. Therefore, the counter CurrentImmediateQUE is set at “1” uponresetting. If the value of the counter CurrentImmediateQUE is largerthan “0”, the value of the counter is decremented by 1 in step S1406.Then, an ORB is linked to the ORB list to write a doorbell.

[0188] Upon write in the DOORBELL register in this way, the fetch agentfetches an ORB into the target in the procedure shown in FIG. 15.

[0189] Processing by Fetch Agent

[0190]FIG. 15 shows the processing procedure executed by the fetch agentof the target upon write in the DOORBELL register 108.

[0191] Upon write in the DOORBELL register 108, the address of the firstlinked ORB in the system memory is set at a read pointer in step S1601.

[0192] In step S1602, the immediate bit of the ORB indicated by the readpointer is tested to check if it is an immediate or queued executioncommand. If the ORB of interest is a queued execution command, the endaddress (NextWritePointer) of the prefetch queue 104 is acquired in stepS1603. Since the host computer writes a doorbell after having confirmedan empty position of the prefetch queue, the queue surely has an emptyposition.

[0193] The ORB indicated by the read pointer is copied to the end of theprefetch queue in step S1604, and the fetch agent informs the queuedexecution agent of ORB reception in step S1605. It is then checked instep S1606 if the “Next_ORB” field (link field to the next ORB) of theORB indicated by the read pointer is NULL, i.e., if a linked ORB ispresent. If that field is NULL, the flow ends; otherwise, the address ofthat linked ORB is set at the read pointer to repeat the flow from stepS1602.

[0194] On the other hand, if it is determined in step S1602 that the ORBis an immediate execution command, that ORB is copied to the addressindicated by the immediate execution agent in advance in step S1608.After that, the fetch agent informs the immediate execution agent of ORBreception in step S1609, and the flow advances to step S1606.

[0195] In this manner, the ORB is fetched into the target to inform eachexecution agent of ORB reception. Then, the ORB is processed by theprocedure shown in FIG. 16.

[0196] Processing by Execution Agent

[0197] There are two types of execution agents, i.e., the immediate andqueued execution agents, but they process ORBs by the same procedure.Hence, their processing will be described simultaneously using FIG. 16.

[0198] When the execution agent is informed of ORB reception from thefetch agent, it extracts the values of the data address field, directionbit, and data size field of the ORB indicated by Nextreadpointer in stepS1701. Note that Nextreadpointer is a pointer which is stored in thequeue and indicates the ORB that the execution agent is about toprocess. This pointer indicates the first ORB in the prefetch queue incase of the queued execution agent.

[0199] It is checked in step S1702 if the extracted data size is “0”. Ifthe size is not “0”, it is checked in step S1703 if the direction bit(Direction bit) indicates a write or read. If the direction bitindicates a write, the execution agent reads out data designated by thedata address and size from the system memory of the initiator and passesthe readout data to the data processor 107 in step S1704.

[0200] The data processor processes the passed data in steps S1705 toS1707. For example, PDL data is interpreted and rasterized in case ofthe printer. In step S1707, the execution agent is informed of the endof processing.

[0201] Upon informing of the end of processing in the data processor,the execution agent generates a DATA TRANSFER status block (normalstatus) as a message indicating the end of processing of the ORB ofinterest in step S1708, and writes that message in the status register210 to inform the initiator of the status in step S1709.

[0202] On the other hand, if it is determined in step S1703 that thedirection bit of the ORB indicates a read, the execution agent writesdata in a data buffer designated by the data address field and data sizefield of the ORB in step S1710. The data written by the target is calledreverse data. The reverse data to be written has been generated by thedata processor 107 or the like and stored in a buffer. For example, thereverse data is data of more than 24 bytes such as a built-in font listof the printer.

[0203] In step S1711, the buffer that stored the data which has beenwritten is released.

[0204] Upon completion of processing, the execution agent generates astatus block (normal status) of a processing completion message in stepS1713, and writes a predetermined value in the status register to informthe host computer of the status block message in step S1714.

[0205] Lastly, in step S1715, the execution agent increments the valueof the counter CurrentUnSolicitedQUE by 1. Upon reception of a QUEUEDEPTH command, the value stored in its “status_que_depth” field is setas the default value of the counter CurrentUnSolicitedQUE. The contentsof this counter are incremented/decremented in correspondence withtransmission of an Unsolicited status block and its processingcompletion message to indicate the number of empty positions of thestatus queue 204. The counter CurrentUnsolicitedQUE is counted under thefollowing condition:

[0206] -Count-down condition

[0207] (1) Upon transmission of an Unsolicited status block, the counteris decremented by 1. In the initiator, unsolicited status alone isqueued in the status queue 204.

[0208] -Count-up condition

[0209] (1) Upon transmission of a processing completion status block ofa REQUESTED READ ORB, the counter is incremented by 1. Upon reception ofthis status, the initiator removes the processed status block from thestatus queue 204.

[0210] (2) Upon transmission of a processing completion status block foran ORB with the data size=0, the counter is incremented by 1. In otherwords, upon transmission of a status block for a DIRECT STATUS RESPONSEORB, the counter is incremented by 1. Upon reception of this status, theinitiator removes the processed status block (direct status) from thestatus queue 204.

[0211] If it is determined in step S1702 that the data size is “0”,since there is no data to be processed, the execution agent returns astatus block without any processing to send a processing completionmessage in step S1713.

[0212] With the aforementioned procedures, generation of an ORB by theinitiator, and its processing and generation of a status block by thetarget are done. Data transfer in response to Unsolicited statustransmitted from the printer to the host computer will be explainedbelow with reference to FIGS. 17 and 18.

[0213] Issuance of Unsolicited Status in Target

[0214] Some kinds of information must be immediately informed from theprinter to the host computer, for example, when errors such asout-of-paper, jam, and the like have occurred in the printer. In suchcase, the printer spontaneously transfers data to the host computerasynchronously with commands from the host computer. If data to be sentfrom the printer is generated, the data processor informs the immediateexecution agent of the presence of such data, thus starting theprocessing in FIG. 17.

[0215] It is checked in step S1801 if the data to be transmitted to thehost computer exceeds 24 bytes. Note that 24 bytes are the upper limitof the data volume that can be stored in the response block of thestatus block.

[0216] If the data exceeds the upper limit value, a READ REQUEST statusblock (Unsolicited status) is generated in step S1802, and the storageaddress of reverse data is set in the “ORB_offset” field of that statusblock in step S1803. At this time, the size of the reverse data is alsowritten in the status block.

[0217] It is checked in step S1804 if the value of the counterCurrentUnsolicitedQUE is larger than “0”, i.e., the status queue has anempty position. If NO in step S1804, after the control waits until thequeue has an empty position, the value of the counterCurrentUnsolicitedQUE is decremented by 1 in step S1805, and anappropriate value is written in the status register in step S1806.

[0218] On the other hand, if the data is equal to or smaller than 24bytes, since that data can be sent to the host computer while beingencapsulated in the status block, DIRECT status (Unsolicited status) isgenerated, and reverse data is stored in its Command set dependentfield. After that, the flow branches to step S1804.

[0219] In this fashion, the Unsolicited status is sent to the initiator.

[0220] Upon reception of the status, the initiator processes it by theprocedure shown in FIG. 18.

[0221] Status Processing by Initiator

[0222] This processing is started by an interrupt that is produced uponsetting a predetermined value in the status register. Multipleinterrupts are permitted; an interrupt is generated every time the valueis set in the status register.

[0223] In step S1501, it is checked if status is normal or Unsolicitedstatus. If the status is Unsolicited status, the status block is readout from the target, and is copied to the end of the status queue instep S1502. It is checked in step S1503 if the block of interest hasmoved to the head position of the queue. If YES in step S1503, a bufferfor storing reverse data is assured in step S1504, and it is checked instep S1505 if the status is READ REQUEST or DIRECT status.

[0224] If the status is READ REQUEST status, a REQUESTED READ commandORB is generated in step S1506. The generated ORB is set with the“immediate” flag, and its direction flag indicates a read. Also, theaddress of the buffer that stores data to be read out is written in theORB. After that, the process shown in FIG. 14 is informed that an eventwhich requires data transfer has taken place in step S1507. The processshown in FIG. 14 sends the ORB generated in step S1506 to the target,and the data from the target is written in the data buffer, thusattaining data transfer.

[0225] If it is determined in step S1505 that the status is DIRECTstatus, reverse data in that status is copied to the assured buffer instep S1508, and is passed to a host process such as an application orthe like in step S1509. After that, a DIRECT STATUS RESPONSE ORB(immediate bit is set at “immediate”) is generated in step S1510. Atthis time, the data size=0 is designated.

[0226] On the other hand, if it is determined in step S1501 that thestatus is normal status, it is checked in step S1511 if the directionbit of the ORB corresponding to that status indicates a read or write.If the direction bit indicates a write, i.e., data transfer from theinitiator to the target, the corresponding ORB is deleted from the list(step S1512), the data buffer used by that ORB is released (step S1513),and the value of the counter CurrentQuedQUE indicating the empty size ofthe prefetch queue is incremented by 1 (S1514).

[0227] On the other hand, if the direction bit indicates a read, i.e.,data transfer from the target to the initiator, since that status is areply to the REQUESTED READ COMMAND ORB, a host process such as aprinter driver or the like is informed of the end of read in step S1515.The corresponding ORB is deleted from the list in step S1516, and thevalue of the counter CurrentImmediateQUE is incremented by 1. That is,the immediate execution agent is ready to send the next ORB.

[0228] In this fashion, upon write in the status register, the initiatorprocesses the status. That is, Unsolicited status is queued and isprocessed in turn, but normal status is processed immediately. Thereason why the Unsolicited status is queued is that it generates an ORB.The number of ORBs generated and linked to the ORB list is limited belowthe total of the processing capacity of the execution agents of thetarget and the size of the prefetch queue. The number of ORBs is limitedin such way to guarantee that the ORB to be immediately executed isprocessed immediately after an ORB generation message. The immediateexecution command is immediately processed by the immediate executionagent as long as it is passed to the target. However, if ORBs aregenerated freely, the ORB list itself unwantedly becomes a queue of ORBsto be processed by the immediate execution agent, and the generated ORBis not passed to the target. As a result, immediate execution is notguaranteed. Since the number of ORBs linked is limited to the totalvalue of the number of ORBs placed in the prefetch queue of the target,and the number of ORBs which are being executed by the execution agents,an ORB generated by the initiator can be immediately passed to thetarget. For this reason, even upon reception of Unsolicited status, theinitiator cannot often generate a new ORB due to the limitation on thenumber of ORBs. Hence, the Unsolicited status is temporarily placed inthe status queue.

[0229] Example of Message Sequence

[0230] An example of the message sequence exchanged between theinitiator and target in the above-mentioned procedures will be explainedbelow with reference to FIGS. 19 to 21.

[0231] Data Transfer Sequence to Target

[0232]FIG. 19 shows an example of the sequence upon data transfer fromthe initiator (host computer) to the target (printer).

[0233] Note that SBP-2 in FIG. 19 represents data specified by the SBP-2standard, i.e., the processing layer that processes the fields specifiedin SBP-2 in the command shown in FIGS. 3A and 3B and status shown inFIGS. 11A and 11B. Also, HPT represents the processing layer thatperforms processing defined in units of functions, which are notspecified in SBP-2. HPT executes the procedures of the above-mentionedflow charts. SBP-2 implements functions of linking ORBs, writing adoorbell, passing an ORB or status to HPT, and the like.

[0234] An application on the initiator generates data and its HPTgenerates an ORB (in this case, data transfer ORB), the value of theempty queue counter (CurrentQuedQUE) is decremented by 1, and an ORBlink request is issued to SBP-2 (1901). SBP-2 links the generated ORB tothe list, and issues a write request to the DOORBELL register (1902).The 1394 interface writes a doorbell in the DOORBELL register (1903),and SBP-2 of the target then receives that message (1904).

[0235] Upon reception of the message, SBP-2 issues an ORB read requestto the 1394 interface (1905), and the ORB is read out from the systemmemory (1906). HPT stores the readout ORB in the corresponding queue incorrespondence with its contents (1907). In this case, since the ORB isa data transfer command ORB, a data read request is issued to the 1394interface (1908). In response to this request, data is read out from thedesignated address and is passed to an application (1909). Theapplication in this case is, e.g., a rasterizer for mapping an image,and the mapped image is printed out by the printer engine.

[0236] After the data is read out, a status block transmission requestis issued to SBP-2 of the target (1910), and a status block (datatransfer status) is sent back to the initiator (1911). Upon reception ofthe status, HPT of the initiator deletes the corresponding ORB from thelink, and increments the empty queue counter (CurrentQuedQUE) by 1(1912).

[0237] With the above-mentioned sequence, data is transferred from theinitiator to the target.

[0238] Data Transfer Sequence to Initiator

[0239]FIG. 20 shows the READ REQUEST status sequence.

[0240] When an application on the target generates data, Unsolicitedstatus (READ REQUEST status) is generated, the status queue counter(CurrentUnsolicitedQUE) is decremented by 1, and an Unsolicited statustransmission request is issued (2001). Upon reception of this request,SBP-2 transmits an Unsolicited status block to the initiator (2002).Upon reception of this status, the SBP-2 layer of the initiatortransmits an Unsolicited status block to the HPT layer (2003). The HPTlayer copies the Unsolicited status block to the status queue.

[0241] For the status at the head position of the status queue, the HPTlayer prepares a data buffer and read request ORB and requests the SBP-2layer to link the generated ORB (2004). The SBP-2 layer issues a writerequest to the DOORBELL register (2005), and the 1394 interface writes adoorbell (2006). A doorbell write message is sent from the 1394interface to SBP-2 (2007), and issuance of a read request of the ORB(2008) and read of the ORB (2009) are immediately done. The readout ORBis passed to the HPT layer of the target, and the HPT layer stores thatORB in the designated queue (2010). After that, the HPT layer interpretsthe contents of the ORB to recognize a data read request, and issues thedata write request to the 1394 interface (2011).

[0242] In response to this request, reverse data is written in the databuffer prepared by the initiator (2012).

[0243] Upon completion of this processing, the target issues a statusblock generation request, and increments the number of empty positionsof the status queue by 1 (2013). In response to the request, a normalstatus block is sent back to the initiator (2014). When an ORB linkdeletion request is issued to HPT in response to that status, thecorresponding ORB is deleted, and the number of empty positions (must be0) of the queue of the immediate execution agent is incremented by 1,thus releasing the used data buffer (2015).

[0244] With this sequence, data is transferred from the target to theinitiator.

[0245] Data Transfer Sequence to Initiator

[0246]FIG. 21 shows the sequence upon data transfer from the target tothe initiator. Unlike in the sequence of FIG. 20, since the data to betransferred is small, DIRECT status is used.

[0247] When an application on the target generates data, Unsolicitedstatus (DIRECT status) is generated, the status queue counter(CurrentUnsolicitedQUE) is decremented by 1, and an Unsolicited statustransmission request is issued (2101). Upon reception of this request,SBP-2 transmits an Unsolicited status block to the initiator (2102).Upon reception of this status, the SBP-2 layer of the initiatortransmits an Unsolicited status block to the HPT layer (2103). The HPTlayer copies the Unsolicited status block to the status queue.

[0248] For the status at the head position of the status queue, the HPTlayer reads out data on the application level encapsulated in thatstatus, prepares a data buffer and DIRECT STATUS RESPONSE ORB, andrequests the SBP-2 layer to link the generated ORB (2104). The SBP-2layer issues a write request to the DOORBELL register (2105), and the1394 interface writes a doorbell (2106). A doorbell write message issent from the 1394 interface to SBP-2 (2107), and issuance of a readrequest of the ORB (2108) and read of the ORB (2109) are immediatelydone.

[0249] The readout ORB is passed to the HPT layer of the target, and theHPT layer stores it in the designated queue (2110). After that, the HPTlayer interprets the contents of the ORB. If it is confirmed that theORB is a DIRECT STATUS RESPONSE ORB, the target issues a correspondingstatus block generation request, and increments the number of emptypositions of the status queue by 1 (2111). In response to this request,a normal status block is sent back to the initiator (2112). When an ORBlink deletion request is issued to HPT in response to that status, thecorresponding ORB is deleted, and the number of empty positions of thequeue of the immediate execution agent is incremented by 1, thusreleasing the used data buffer (2113).

[0250] With this sequence, data is transferred from the target to theinitiator. In this sequence, two steps, i.e., a data write request(2011) and write of reverse data (2012), are omitted as compared to thatshown in FIG. 20.

[0251] Functions Unique to This System

[0252] The arrangement and operation of this system are as has beendescribed above. The functions, arrangement, merits, and the like uniqueto this system are summarized below:

[0253] (1) Two execution agents, i.e., queued and immediate executionagents are prepared in the target, and command queues are provided incorrespondence with these execution agents. In this way, data transferrequest ORBs from the initiator are queued and processed in turn (queuedexecution), but READ REQUEST status from the target is processedimmediately after a corresponding (REQUESTED READ ORB) is issued(immediate execution). The immediate execution is guaranteed since theupper limit of the number of ORBs linked to the ORB list is limited tothe size of the queued execution queue for write ORBs, and is limited tothe size (1 in this case) of the immediate execution queue for readORBs.

[0254] On the other hand, READ REQUEST status from the target is queuedin the initiator. For this reason, a data transfer request from theinitiator is appended to the prefetch queue, and a data transfer request(read request) from the target is added to the status queue. With thiscontrol, full-duplex communication channels can be provided between theapplications on the initiator and target. That is, irrespective of thedata transfer direction, requests appended to the queues are processedin the FIFO order, and data transfer in one direction does not influencethat in the other direction, thus providing independent channels whichdo not interfere with each other. In other words, data generated in theinitiator or target can be asynchronously transferred from the initiatorto the target or vice versa.

[0255] (2) Since the initiator and target monitor the empty sizes ofeach others' queues, the transmitted ORB or status block is reliablyreceived.

[0256] (3) Full-duplex communication channels are provided by a singlelogin process. That is, since data can be exchanged using the computerwith many resources as the initiator and the printer with poor resourcesas the target, the resources of the printer, especially, the requiredmemory capacity, can be suppressed.

[0257] (4) Since the IEEE1394 interface is used, data transfer to thetarget can be done when the target reads out data as its resourcesbecome available, and the initiator can be prevented from being occupiedby data transfer on the convenience of the target. If the printer servesas the target, it can read out data passed from the computer as itsresources become available. For this reason, the host computer need notexecute processing for monitoring the printer and starting data transferafter it confirms that the printer is ready to receive data. That is,the host computer can send data to the printer irrespective of theprinter state, and need not transfer data after the printer becomesavailable.

[0258] (5) Since SBP-2 is used, an ORB alone is queued in the target,and data to be transferred itself is stored in the initiator in theprocessing wait time. For this reason, the memory resources of thetarget can be minimized.

[0259] (6) Using DIRECT status, data of the application layer can beencapsulated in status of the HPT layer, and can be transmitted from thetarget to the initiator. For this reason, the data transfer sequence canbe shortened.

[0260] Note that the system of this embodiment is not limited to thehost computer and printer, but maybe applied to various otherapparatuses. The above-mentioned features are effective not only for therelationship between a host computer and printer, but also forconnections between a host computer and a peripheral apparatus withsmall resources, and between peripheral apparatuses.

[0261] Second Embodiment

[0262] A system that simultaneously provides a plurality of logicalchannels will be explained as the second embodiment of the presentinvention. In this case, on the target side, a digital multi-functionalmachine that combines a printer, facsimile, and image scanner can beused in place of the printer alone.

[0263] System Arrangement

[0264]FIG. 23 is a block diagram of an initiator of this embodiment. InFIG. 23, only the differences from FIG. 2 will be explained, and adescription of the common components will be omitted. The characteristicfeatures of FIG. 23 are that a status identifier 212 identifies not onlythe type of status but also logical channels and distributes statusblocks in units of channels, and has an arrangement with a system memoryand HPT processor per channel for a plurality of (2 in FIG. 23)channels.

[0265] Note that the status identifier 212 identifies a channel inaccordance with the channel ID included in a status block. This will bedescribed later. For example, when a digital multi-functional machine isused, different applications may be assigned in units of channels, i.e.,one channel is used by a printer driver and the other channel by animage scanner driver, or a single application may use a plurality ofchannels.

[0266]FIG. 22 is a block diagram of a target. The difference from FIG. 1lies in that a command fetch agent 113 distributes command ORBs in unitsof channels. Each channel has the same arrangement as that in FIG. 1,and has a prefetch queue and two execution agents (queued and immediateexecution agents).

[0267] Note that an ORB indicates a logical channel, and the commandfetch agent identifies a channel with reference to it.

[0268] Format of Command ORB

[0269] FIGS. 24 to 32B show examples of the formats of command ORBs.FIG. 24 shows a data transfer command ORB, FIG. 25 shows a REQUESTEDREAD command ORB, FIG. 26 shows a DIRECT STATUS RESPONSE command ORB,FIGS. 27A and 27B show an ACQUIRE DEVICE RESOURCE command ORB, FIG. 28shows a RELEASE DEVICE RESOURCE command ORB, and FIG. 30 shows a BASICDEVICE STATUS command ORB. These command ORBs are substantially the sameas those in the first embodiment, except that they have channel IDfields.

[0270]FIG. 29 shows an ABDICATE DEVICE RESOURCE RESPONSE command ORB,which is a response to an ABDICATE DEVICE RESOURCE request from thetarget. Since the target has poor resources, the resources of processesmay become short when a plurality of channels are used and when aplurality of application processes are running. In such case, the targetissues the ABDICATE DEVICE RESOURCE request.

[0271]FIG. 31A shows an OPEN CHANNEL REQUEST command used for issuing achannel open request, and FIG. 31B shows OPEN CHANNEL REQUEST statuscorresponding to that command. With these command and status, a desiredlogical channel is opened.

[0272]FIG. 32A shows a CLOSE CHANNEL REQUEST command used for issuing achannel close request, and FIG. 32B shows CLOSE CHANNEL REQUEST statuscorresponding to that command. With these command and status, a desiredlogical channel is closed.

[0273] Format of Status Block

[0274]FIGS. 33A to 38 show the formats of status blocks. FIGS. 33A to33C show the general format of status, FIG. 34 shows READ REQUESTstatus, FIG. 35 shows DIRECT status, FIG. 36 shows ACQUIRE DEVICERESOURCE status, and FIG. 38 shows BASIC DEVICE status. The formats ofthese status blocks are substantially the same as those of the firstembodiment, except that they include channel IDs.

[0275]FIG. 37 shows an ABDICATE DEVICE RESOURCE status block, whichstores a resource ID, which is used for requesting the initiator toabdicate, in a resource ID field 3701. Since this status is a requestissued by the target, it is transmitted as Unsolicited status to theinitiator.

[0276] Command/status Processing Procedure in Initiator and Target

[0277]FIGS. 39A and 39B show the processing procedures in the initiatorand target of this embodiment. FIG. 39A shows the processing procedurestarted upon write in a status register in the initiator, andcorresponds to FIG. 18 of the first embodiment. When the processing isstarted, the channel ID is discriminated in step S3901. After that, thesame processing as that in step S1501 and subsequent steps in FIG. 18 isexecuted for the discriminated channel.

[0278]FIG. 39B shows the processing procedure started upon write in aDOORBELL register in the target, and corresponds to FIG. 15 in the firstembodiment. When the processing is started, the channel ID isdiscriminated in step S3911. After that, the same processing as that instep S1601 and subsequent steps in FIG. 15 is executed for thediscriminated channel.

[0279] In addition, the processing that starts in response to a datatransfer request (FIG. 14), the processing by the target agent (FIG.16), and the processing upon generation of data to be transferred fromthe printer to the host computer (FIG. 17) are the same as those in thefirst embodiment. However, before such processing, a channel must beopened.

[0280] Also, an ABDICATE RESOURCE request from the target is issued inthe same sequence as that of data transfer using DIRECT status from thetarget.

[0281] In this embodiment, data transfer is done by the above-mentionedprocedures. The system of this embodiment is substantially the same asthat in the first embodiment, except that a plurality of logicalchannels can be used.

[0282] This system can provide full-duplex communications for each of aplurality of logical channels. For this reason, two-way communicationscan be provided even for equipment having a plurality of devices such asa digital multi-functional machine. Hence, the functions (1) to (6)described in the first embodiment can be provided for a plurality ofchannels.

[0283] Other Embodiments

[0284] Note that the present invention may be applied to either a systemconstituted by a plurality of equipments (e.g., a host computer,interface device, reader, printer, and the like), or an apparatusconsisting of a single equipment (e.g., a copying machine, facsimileapparatus, or the like).

[0285] The objects of the present invention are also achieved bysupplying a storage medium, which records a program code (i.e., programsof the procedures shown in FIGS. 14 to 18 and FIGS. 39A and 39B) of asoftware program that can realize the functions of the above-mentionedembodiments to the system or apparatus, and reading out and executingthe program code stored in the storage medium by a computer (or a CPU,MPU, or the like) of the system or apparatus.

[0286] In this case, the program code itself read out from the storagemedium realizes the functions of the above-mentioned embodiments, andthe storage medium which stores the program code constitutes the presentinvention.

[0287] As the storage medium for supplying the program code, forexample, a floppy disk, hard disk, optical disk, magneto-optical disk,CD-ROM, CD-R, magnetic tape, nonvolatile memory card, ROM, and the likemay be used.

[0288] The functions of the above-mentioned embodiments may be realizednot only by executing the readout program code by the computer but alsoby some or all of actual processing operations executed by an OS(operating system) running on the computer on the basis of aninstruction of the program code.

[0289] Furthermore, the functions of the above-mentioned embodiments maybe realized by some or all of actual processing operations executed by aCPU or the like arranged in a function extension board or a functionextension unit, which is inserted in or connected to the computer, afterthe program code read out from the storage medium is written in a memoryof the extension board or unit.

[0290] To restate, according to the present invention, full-duplexcommunications that allow asynchronous, two-way communications can berealized by a single login process, and resources such as processes,memories, and the like required for data exchange can be efficientlyused.

[0291] Since the initiator and target monitor the empty sizes of eachothers' queues, an ORB or status block transmitted can be reliablyreceived.

[0292] Since the IEEE1394 interface is used, data transfer to the targetcan be done when the target reads out data as its resources becomeavailable, and the initiator can be prevented from being occupied bydata transfer on the convenience of the target.

[0293] Since SBP-2 is used, an ORB alone is queued in the target, anddata to be transferred itself is stored in the initiator in theprocessing wait time. For this reason, the memory resources of thetarget can be minimized.

[0294] Using DIRECT status, data of the application layer can beencapsulated in status of the HPT layer, and can be transmitted from thetarget to the initiator. For this reason, the data transfer sequence canbe shortened.

[0295] Also, multi-channels can be realized.

[0296] As many apparently widely different embodiments of the presentinvention can be made without departing from the spirit and scopethereof, it is to be understood that the invention is not limited to thespecific embodiments thereof except as defined in the appended claims.

What is claimed is:
 1. A communication control method of exchanging dataupon accessing a storage area of an initiator from a target, whereinsaid initiator transmits commands corresponding to read and writeaccesses to said storage area to said target so as not to exceed thenumber of read and write commands that can be held by said target, andsaid target holds the received read and write commands in differentqueues, and independently processes the held commands.
 2. The methodaccording to claim 1, wherein said target holds the write command in aqueue having capacity of one and process the command in the queue. 3.The method according to claim 1, wherein upon reception of a data writerequest in said storage area from said target, said initiator holds therequest in a second queue, and issues a write command to said target. 4.The method according to claim 3, wherein said target issues writerequests to said initiator so as not to exceed the number of requeststhat can be held by said second queue.
 5. The method according to claim1, wherein said initiator issues a write command in said storage area inresponse to a request from said target.
 6. The method according to claim5, wherein when data to be transferred to said initiator is smaller thana predetermined size, said target does not request said initiator towrite in said storage area, and directly writes the data in apredetermined area of said storage area in said initiator.
 7. Acommunication control method of exchanging data upon accessing a storagearea of an initiator from a target, wherein said target checks if a sizeof data to be transmitted exceeds a predetermined size, requests saidinitiator to issue a write command in said storage area when the size ofthe data to be transmitted exceeds the predetermined size, and sends thedata to said initiator when the size of the data to be transmitted doesnot exceed the predetermined size, and said initiator issues a writecommand upon receiving a write command issuance request from saidtarget.
 8. The method according to claim 1, wherein said target andinitiator assign channel identifiers to the write and read commands, andindependently process the commands in units of channel identifiers.
 9. Acommunication system for exchanging data upon accessing a storage areaof an initiator from a target, wherein said initiator transmits commandscorresponding to read and write accesses to said storage area to saidtarget so as not to exceed the number of read and write commands thatcan be held by said target, and said target holds the received read andwrite commands in different queues, and independently processes the heldcommands.
 10. The system according to claim 9, wherein said target holdsthe write command in a queue having capacity of one and processes thecommand in the queue.
 11. The system according to claim 9, wherein uponreception of a data write request in said storage area from said target,said initiator holds the request in a second queue, and issues a writecommand to said target.
 12. The system according to claim 11, whereinsaid target issues write requests to said initiator so as not to exceedthe number of requests that can be held by said second queue.
 13. Thesystem according to claim 9, wherein said initiator issues a writecommand in said storage area in response to a request from said target.14. The system according to claim 13, wherein when data to betransferred to said initiator is smaller than a predetermined size, saidtarget does not request said initiator to write in said storage area,and directly writes the data in a predetermined area of said storagearea in said initiator.
 15. A communication system for exchanging dataupon accessing a storage area of an initiator from a target, whereinsaid target checks if a size of data to be transmitted exceeds apredetermined size, requests said initiator to issue a write command insaid storage area when the size of the data to be transmitted exceedsthe predetermined size, and sends the data to said initiator when thesize of the data to be transmitted does not exceed the predeterminedsize, and said initiator issues a write command upon receiving a writecommand issuance request from said target.
 16. The system according toclaim 9, wherein said target and initiator assign channel identifiers tothe write and read commands, and independently process the commands inunits of channel identifiers.
 17. A communication control method ofexchanging data with a target upon accessing a storage area in a memoryfrom said target connected via a communication, comprising: a queuingstep of receiving a spontaneous request from said target and queuing therequest in a queue; and a command generation step of generating andtransmitting read and write commands to said storage area in response toa request from an application or said target so as not to exceed thenumber of read and write commands that can be held by said target.
 18. Acommunication control method of exchanging data with an initiator uponaccessing a storage area of said initiator connected via acommunication, comprising: a queuing step of queuing a read commandreceived from said initiator in a queue having a predetermined size; aqueued execution step of picking up and executing a read command fromsaid queue; an immediate execution step of executing a write commandreceived from said initiator immediately after reception; and a transferrequest step of issuing a data transfer request to said initiator. 19.The method according to claim 18, further comprising a channeldiscrimination step of discriminating a channel corresponding to therequest from said target using a channel identifier, and wherein thecommand generation step includes a step of assigning a channelidentifier corresponding to the discriminated channel or a channelcorresponding to an application to the command.
 20. The method accordingto claim 19, further comprising a channel discrimination step ofdiscriminating a channel corresponding to the command from saidinitiator using a channel identifier, and the response step of sendingback a response assigned with a channel identifier corresponding to thediscriminated channel to said initiator, and wherein the transferrequest step includes a step of assigning a channel identifiercorresponding to the discriminated channel or a channel corresponding toan application to the request.
 21. The method according to claim 20,wherein the transfer request step includes a step of requesting saidinitiator to issue a data write command in said storage area when a sizeof data for said initiator is larger than a predetermined size, anddirectly writing the data in a predetermined area of said storage areawhen the size of the data is smaller than the predetermined size.
 22. Acommunication control apparatus for exchanging data with a target via astorage area, comprising: means for communicating with a target; amemory including said storage area; queue management means for queuing aspontaneous request from said target; and command generation means forgenerating and transmitting read and write commands with respect to saidstorage area in response to a request from an application or said targetso as not to exceed the number of read and write commands that can beheld by said target.
 23. A communication control apparatus forexchanging data with an initiator by accessing a storage area of saidinitiator, comprising: means for communicating with said initiator; aqueue which holds a read command received from said initiator and has apredetermined size; queued execution means for picking up and executingthe read command from said queue; immediate execution means forexecuting a write command received from said initiator immediately afterreception; and transfer request means for issuing a data transferrequest to said initiator.
 24. The apparatus according to claim 22,further comprising channel discrimination means for discriminating achannel corresponding to the request from said target using a channelidentifier, and wherein said command generation means assigns a channelidentifier corresponding to the discriminated channel or a channelcorresponding to an application to the command.
 25. The apparatusaccording to claim 23, further comprising channel discrimination meansfor discriminating a channel corresponding to the command from saidinitiator using a channel identifier, and response means for sendingback a response assigned with a channel identifier corresponding to thediscriminated channel to said initiator, and wherein said transferrequest means assigns a channel identifier corresponding to thediscriminated channel or a channel corresponding to an application tothe request.
 26. The apparatus according to claim 25, wherein saidtransfer request means requests said initiator to issue a data writecommand in said storage area when a size of data for said initiator islarger than a predetermined size, and directly writes the data in apredetermined area of said storage area when the size of the data issmaller than the predetermined size.
 27. A computer readable storagemedium, which stores a communication control program for exchanging databy accessing a storage area from a target via a communication, saidprogram comprising: a queue management processing step for queuing aspontaneous request from said target; and a command generationprocessing step for generating and transmitting read and write commandswith respect to said storage area in response to a request from anapplication or said target so as not to exceed the number of read andwrite commands that can be held by said target.
 28. A computer readablestorage medium, which stores a communication control program forexchanging data by accessing a storage area of an initiator connectedvia a communication, said program comprising: a queue managementprocessing step for queuing a read command received from said initiatorin a queue having a predetermined capacity; a queued executionprocessing step for picking up and executing the read command from saidqueue; an immediate execution processing step for executing a writecommand received from said initiator immediately after reception; and atransfer request processing step for issuing a data transfer request tosaid initiator.
 29. The medium according to claim 27, wherein saidprogram further comprises a channel discrimination processing step fordiscriminating a channel corresponding to the request from said targetusing a channel identifier, and said command generation processing stepassigns a channel identifier corresponding to the discriminated channelor a channel corresponding to an application to the command.
 30. Themedium according to claim 28, wherein said program further comprises achannel discrimination processing step for discriminating a channelcorresponding to the command from said initiator using a channelidentifier, and a response processing step for sending back a responseassigned with a channel identifier corresponding to the discriminatedchannel to said initiator, and said transfer request means assigns achannel identifier corresponding to the discriminated channel or achannel corresponding to an application to the request.
 31. The mediumaccording to claim 30, wherein said transfer request processing steprequests said initiator to issue a data write command in said storagearea when a size of data for said initiator is larger than apredetermined size, and directly writes the data in a predetermined areaof said storage area when the size of the data is smaller than thepredetermined size.
 32. A printing system using a communication controlmethod of claim 1, wherein a host apparatus serving as an initiator isconnected to a printer apparatus serving as a target, said printerapparatus receives print data from said host apparatus and prints outbased on the received print data, and said host apparatus receivesstatus information of said printer apparatus.
 33. A printing controlapparatus for transmitting print data to a target, and receiving statusinformation from said target, in a communication control method of claim17.
 34. A printing apparatus for receiving print data from an initiator,and transmitting status information to said initiator, by acommunication control method of claim 18.